BBS in a Box 7/BBS in a Box - Macintosh - Volume VII (BBS in a Box) (January 1993).iso/Files/Tele/P/Policy4.03.cpt/POLICY4.TXT

Text File | 1989-04-05 | 68KB | 1,646 lines

                            FidoNet Policy Document               Version 4.03
                                 *** DRAFT ***                  March 24, 1989


This policy document has been released for comment, and is not yet in force.
Please direct comments to your Network Coordinator.



1  Overview


1.0  Language

The official language of FidoNet is English.  All documents must exist in
English.  Translation into other languages is encouraged.


1.1  Introduction

FidoNet is an amateur electronic mail system.  As such, all of its partici-
pants and operators are unpaid volunteers.  From its early beginning as a few
friends swapping messages back and forth (1984), it now (1989) includes over
5,000 systems on six continents.

FidoNet is not a common carrier or a value-added service network and is a
public network only in as much as the independent, constituent nodes may
individually provide public access to the network on their system.

FidoNet is large enough that it would quickly fall apart of its own weight
unless some sort of structure and control were imposed on it.  Multinet
operation provides the structure. Decentralized management provides the
control.  This document describes the procedures which have been developed to
manage the network.


1.2  Organization

FidoNet nodes are grouped on several levels.

Separate documents may be issued at the zone, region, or net level to provide
additional detail on local procedures.  Ordinarily, these lower-level
policies may not contradict this policy.  However, with the approval of the
International Coordinator, local policy can be used to implement differences
required due to local requirements.  The Zone Coordinator Council may reverse
the decision of the International Coordinator.  These local policies may not
place additional restrictions on members of FidoNet beyond those included in
this document, other than enforcement of local mail periods.


1.2.1  Points

A point is a FidoNet-compatible system that is not in the nodelist, but
communicates with FidoNet through a node referred to as a bossnode.  A point
is generally regarded in the same manner as a user, for example, the bossnode
is responsible for mail from the point.  (See section 2.1.3.)  Points are
addressed by using the bossnode's nodelist address; for example, a point
system with a bossnode of 114/15 might be known as 114/15.12.  Mail destined
for the point is sent to the bossnode, which then routes it to the point.

In supporting points, the bossnode makes use of a private net number which
should not be visible outside of the bossnode-point relationship except as
the first entry in the ^aPATH line.  Unfortunately, should the point call
another system directly (to do a file request, for example), the private
network number will appear as the caller's address.  In this way, points are
different from users, since they operate FidoNet-compatible mailers which are
capable of contacting systems other than the bossnode.

1.2.2  Nodes

A node is a single FidoNet address, and is the smallest official unit of
FidoNet.


1.2.3  Networks

A network is a collection of nodes in a local geographic area.  Networks
coordinate their mail activity to decrease cost.

1.2.3  Regions

A region is a well-defined geographic area containing nodes which may or may
not be combined into networks.  A typical region will contain many nodes in
networks, and a few independent nodes which are not a part of any network.

1.2.5  Zones

A zone is a large geographic area containing many regions, covering one or
more countries and/or continents.


1.2.6  FidoNet

FidoNet indicates the entire amateur mail network as defined by the weekly
nodelist (see section 1.3.4).


1.3  Definitions

1.3.1  FidoNews

FidoNews is a weekly newsletter distributed throughout the network by the
coordinator structure.  It is an important medium by which FidoNet sysops
communicate with each other.  FidoNews provides a sense of being a community
of people with common interests.  Accordingly, sysops and users are encour-
aged to contribute to FidoNews.  Contributions are submitted to node 1/1; a
file describing the format to be used is available on many systems.


1.3.2  Geography

Each level of FidoNet is geographically contained by the level immediately
above it.  A given geographic location is covered by one zone and one region
within that zone, and is either in one network or not in a network.  There
are never two zones, two regions, or two networks which cover the same
geographic area.

If a node is in the area of a network, it should be listed in that network,
not as an independent in the region.  (The primary exception to this is a
node receiving inordinate amounts of host-routed mail; see section 4.2).
Network boundaries are based on calling areas as defined by the local
telephone company.  Even in the case of areas where node density is so great
that more than one network is needed to serve one local calling area, a geo-
graphic guideline is used to decide which nodes belong to what network.
Network membership is based on geographic or other purely technical ratio-
nale.  It is not based on personal or social factors.

There are cases in which the local calling areas lead to situations where
logic dictates that a node physically in one FidoNet Region should be
assigned to another.  In those cases, with the agreement of the Regional
Coordinators and Zone Coordinator involved, exemptions may be granted.  Such
exemptions are described in section 5.6.

1.3.3  Zone Mail Hour

Zone Mail Hour (ZMH) is a defined time during which all nodes in a zone are
required to be able to accept netmail.  Each Fidonet zone defines a ZMH and
publishes the time of its ZMH to all other Fidonet zones.  See sections 2.1.8
and 10.2.

Zone Mail Hour has previously been referred to as National Mail Hour and
Network Mail hour.  The term Zone Mail Hour is more accurate.

1.3.4  Nodelist

The nodelist is a file updated weekly which contains the addresses of all
recognized FidoNet nodes.  This file is currently made available by the Zone
Coordinator not later than Zone Mail Hour each Saturday, and is available
electronically for download or file request at no charge.  To be included in
the nodelist, a system must meet the standards defined by this document.  No
other requirements may be imposed.

Partial nodelists (single-zone, for example) may be made available at
different levels in FidoNet.  The full list as published by the International
Coordinator is regarded as the official FidoNet nodelist, and is used in
circumstances such as determination of eligibility for voting.  All parts
that make up the full nodelist are available on each Zone Coordinator's and
each Regional Coordinator's system.


1.3.5  Excessively Annoying Behavior

There are references throughout this policy to "excessively annoying behav-
ior", especially in section 9 (Resolution of Disputes).  It is difficult to
define this term, as it is based upon the judgement of the coordinator
structure.  Generally speaking, annoying behavior irritates, bothers, or
causes harm to some other person.  It is not necessary to break a law to be
annoying.  Refer to section 9 and the case studies (section 10.3) for more
information.

1.4  Administration of FidoNet


FidoNet has a hierarchical structure for administration of the network, with
the following levels:


1.4.1  International Coordinator

The International Coordinator is the "first among equals" Zone Coordinator.
He coordinates the joint production of the master nodelist by his fellow Zone
Coordinators.

The International Coordinator acts as the chair of the Zone Coordinator
Council and as the overseer of elections -- arranging the announcement of
referenda, the collection and counting of the ballots, and announcing the
results for those issues that affect FidoNet as a whole.


1.4.2  Zone Coordinator Council

In certain cases, the Zone Coordinators work as a council to provide advice
to the International Coordinator.  The arrangement is similar to that between
a president and advisors.  In particular, this council considers inter-zonal
issues.  This includes, but is not limited to: working out the details of
nodelist production, mediating inter-zonal disputes, and such issues not
addressed at a lower level of FidoNet.


1.4.3  Zone Coordinator

The Zone Coordinator compiles the nodelists from all of the regions in the
zone, and creates the master nodelist and difference file, which is then
distributed over FidoNet in the zone.  A Zone Coordinator does not perform
routing services for the zone.


1.4.4  Regional Coordinator

The Regional Coordinator maintains the list of independent nodes in the
region and accepts nodelists from the Network Coordinators in the region.  He
compiles these lists to create a regional nodelist, which he then sends to
the Zone Coordinator.  A Regional Coordinator does not perform routing
services for any nodes in the region.


1.4.5  Network Coordinator

The Network Coordinator is responsible for maintaining the list of nodes for
the network, and for forwarding netmail sent to the network from other
FidoNet nodes.  The Network Coordinator may make arrangements to handle
outgoing netmail, but is not required to do so.  The Network Coordinator is
not required to provide a source for echomail.


1.4.6  Network Routing Hub

Network Routing Hubs exist only in some networks.  They share duties of the
Network Coordinator, in order to ease the management of a large network.  The
exact duties and procedures are a matter for the Network Coordinator and his
hubs to arrange, and will not be discussed here, except that a network
coordinator cannot delegate responsibility to mediate disputes.


1.4.7  System Operator

The system operator (sysop) formulates a policy for running his board and
dealing with users.  The sysop must mesh with the rest of the FidoNet system
if he is to send and receive mail, and the local policy must be consistent
with other levels of FidoNet.


1.4.8  User

The sysop is responsible for the actions of any user when they affect the
rest of FidoNet.  (If a user is annoying, the sysop is annoying.)  Any
traffic entering FidoNet via a given node, if not from the sysop, is consid-
ered to be from a user, and is the responsibility of the sysop.  This
includes messages from point systems.


1.4.9  Summary

These levels act to distribute the administration and control of FidoNet to
the lowest possible level, while still allowing for coordinated action over
the entire mail system.  Administration is made possible by operating in a
top-down manner.  That is, a person at any given level is responsible to the
level above, and responsible for the level below.

For example, a Regional Coordinator is responsible to the Zone Coordinator
for anything that happens in the region.  From the point of view of the Zone
Coordinator, the Regional Coordinator is completely responsible for the
smooth operation of the region.  Likewise, from the point of view of the
Regional Coordinator, the Network Coordinator is completely responsible for
the smooth operation of the network.

If a person at any level above sysop is unable to properly perform their
duties, the person at the next level may replace them.  For example, if a
Regional Coordinator fails to perform, the Zone Coordinator can replace him.

The exceptions to this top down organization are the Zone and International
Coordinators.  See sections 6.2 and 7.2.


2  Sysop Procedures

2.1  General

2.1.1  The Basics

The sysop of an individual node can generally do as he pleases, as long as he
observes the mail events, is not excessively annoying to other nodes on
FidoNet, and does not promote or participate in the distribution of pirated
copyrighted software or other illegal behavior via FidoNet.


2.1.2  Familiarity with Policy

In order to understand the meaning of "excessively annoying", it is incumbent
upon all sysops to occasionally re-read FidoNet policy.  New sysops must
familiarize themselves with policy before requesting a node number.


2.1.3  Responsible for All Traffic Entering FidoNet Via His Node

A Sysop is responsible for all traffic entering FidoNet via his system.  This
includes (but is not limited to) traffic entered by his users, points, and
any other networks for which he might act as a gateway.  If a sysop allows
"outside" messages to enter FidoNet via his system, he has a responsibility
to ensure his system is clearly identified by FidoNet node number as the
point of origin of that message, and a responsibility to act as a gateway in
the reverse direction.  Should such traffic result in a violation of Policy,
the sysop must rectify the situation.


2.1.4  Encryption and Review of Mail

FidoNet is an amateur system.  Our technology is such that the privacy of
messages cannot be guaranteed.  Any sysop has the right to review traffic
flowing through his system, if for no other reason than to ensure that the
system is not being used for illegal purposes.  Encryption obviously makes
this review impossible.  Therefore, encrypted and/or commercial traffic that
is routed without the express permission of all the links in the delivery
system constitutes annoying behavior.


2.1.5  No Alteration of Routed Mail

A sysop may not modify, other than as required for routing or other technical
purposes, any message, netmail or echomail, passing through the system from
one FidoNet node to another.  If a sysop is offended by the content of a
message, he must follow the procedure described in section 2.1.7.


2.1.6  Private Netmail

The word "private" should be used with great care, especially with users of a
BBS.  Some countries have laws which deal with "private mail", and it should
be made clear that the word "private" does not imply that no person other
than the recipient can read messages.  Sysops who cannot provide this
distinction should consider not offering users the option of "private mail".

If a user sends a "private message", the user has no control over the number
of intermediate systems through which that message is routed.  A sysop who
sends a message to another sysop can control this aspect by sending the
message direct to the recipient's system, thus guaranteeing that only the
recipient or another individual to whom that sysop has given authorization
can read the message.  Thus, a sysop may have different expectations than a
casual user.

2.1.6.1  No Disclosure of in-transit mail

Disclosing or in any way using information contained in private netmail
traffic not addressed to you or written by you is considered annoying
behavior, regardless of how you come upon that traffic.  This does not apply
to echomail which is by definition a broadcast medium, and where private mail
is often used to keep a sysop-only area restricted.

2.1.6.2  Private mail addressed to you

The issue of private mail which is addressed to you is more difficult than
the in-transit question treated in the previous section.  A common legal
opinion holds that when you receive a message it becomes your property and
you have a legal right to do with it what you wish.  Your legal right does
not excuse you from annoying others.

In general, sensitive material should not be sent using FidoNet.  This ideal
is often compromised, as FidoNet is our primary mode of communication.  In
general, if the sender of a message specifically requests in the text of the
message that the contents be kept confidential, release of the message into a
public forum may be considered annoying.

There are exceptions.  If someone is saying one thing in public and saying
the opposite in private mail, the recipient of the private mail should not be
subjected to harassment simply because the sender requests that the message
not be released.  Judgement and common sense should be used in this area as
in all other aspects of FidoNet behavior.

2.1.7  Not Routing Mail

A sysop is not required to route traffic if he has not agreed to do so.  He
is not obligated to route traffic for all if he routes it for any, unless he
holds a Network Coordinator or Hub Coordinator position.  Routing traffic
through a node not obligated to perform routing without the permission of
that node may be annoying behavior.  This includes unsolicited echomail.

If a sysop does not forward a message when he had previously agreed to
perform such routing, the message must be returned to the sysop of the node
at which it entered FidoNet with an explanation of why it was not forwarded.
(It is not necessary to return messages which are addressed to a node which
is not in the current nodelist.)  Intentionally stopping an in-transit
message without following this procedure constitutes annoying behavior.  In
the case of a failure to forward traffic due to some technical problem, it
does not become annoying unless it persists after being pointed out to the
sysop.


2.1.8  Exclusivity of Zone Mail Hour

Zone Mail Hour is the heart of FidoNet, as this is when network mail is
passed between systems.  Any system which wishes to be a part of FidoNet must
be able to receive mail from any node in the nodelist during this time.  This
time is exclusively reserved for netmail.  Many phone systems charge on a
per-call basis, regardless of whether a connect, no connect, or busy signal
is encountered.  For this reason, any activity other than normal network mail
processing that ties up a system during ZMH is considered annoying behavior.
Echomail should not be transferred during ZMH.  User (BBS) access to a system
is prohibited during ZMH.

A system which is a member of a local network may also be required to observe
additional mail events, as defined by the Network Coordinator.  Access
restrictions during local network periods are left to the discretion of the
Network Coordinator.


2.1.9  Private Nodes

The rare exception to ZMH compliance is Private Nodes.  Persons requesting
private nodes should be supported as points if possible.  A private listing
is justified when the system must interface with many others, such as an
echomail distributor.  In these cases, the exact manner and timing of mail
delivery is arranged between the private node and other systems.  Such an
agreement between a private system and a hub is not binding on any replace-
ment for that hub.  A private node must be a part of a network (they cannot
be independents in the region.)  Private nodes are encouraged to honor ZMH.


2.1.10  Observing Mail Events

Failure to observe the proper mail events is grounds for any node to be
dropped from FidoNet without notice (since notice is generally given by
netmail).


2.1.11  Use of Current Nodelist

Network mail systems generally operate unattended, and place calls at odd
hours of the night.  If a system tries to call an incorrect or out-of-date
number, it could cause some poor citizen's phone to ring in the wee hours of
the morning, much to the annoyance of innocent bystanders and civil authori-
ties.  For this reason, a sysop who sends mail is obligated to obtain and use
the most recent edition of the nodelist as is practical.


2.1.12  Excommunication

A system which has been dropped from the network is said to be excommunicated
(i.e. denied communication).  If you find that you have been excommunicated
without warning, your coordinator was unable to contact you.  You should
rectify the problem and contact your coordinator.

Systems may also be dropped from the nodelist for cause.  See section 9, and
sections 4.3 and 5.2.

It is considered annoying behavior to assist a system which was excommuni-
cated in circumventing that removal from the nodelist.  For example, if you
decide to provide an echomail feed to your friend who has been excommuni-
cated, it is likely that your listing will also be removed.


2.1.13  Timing of Zone Mail Hour

The exact timing of Zone Mail Hour for each zone is set by the Zone Coordina-
tor.  See section 10.2.


2.1.14  Non-observance of Daylight Savings Time

FidoNet does not observe daylight savings time.  In areas which observe
daylight savings time the FidoNet mail schedules must be adjusted in the same
direction as the clock change.  Alternatively, you can simply leave your
system on standard time.


2.2  How to obtain a node number


You must first obtain a current nodelist so that you can send mail.  You do
not need a node number to send mail, but you must have one in order for
others to send mail to you.

The first step in obtaining a current nodelist is to locate a FidoNet
bulletin board.  Most bulletin board lists include at least a few FidoNet
systems, and usually identify them as such.  Use a local source to obtain
documents because many networks have detailed information available which
explains the coverage area of the network and any special requirements or
procedures.

Once you have a nodelist, you must determine which network or region covers
your area.  Regions are numbered 1-99; network numbers are greater than 99.
Networks are more restricted in area than regions, but are preferred since
they improve the flow of mail and provide more services to their members.  If
you cannot find a network which covers your area, then pick the region which
does.

Once you have located the network or region in your area, send a message
containing a request for a node number to node zero of that network or
region.  The request must be sent by netmail, use address -1/-1, and include
the following:

    1) Your name.
    2) The name of your system.
    3) The city and state where your system is located.
    4) The phone number to be used when calling your system.
    5) Your hours of operation, netmail and BBS.
    6) The maximum baud rate you can support.

You must indicate that you have read, and agree to abide by, this document
and all the current and future policies of FidoNet.

Using a node number other than -1/-1 can cause problems for the coordinator
involved.  Simply assigning yourself a net/node number can be annoying, and
can be grounds to reject your request.

Your coordinator may want additional information.  If so, he will contact
you.

Please allow at least two weeks for a node number request to be processed.
If you send your request to a Regional Coordinator, he may forward it to the
appropriate Network Coordinator.


2.3  If You are Going Down

If your node will be down for an extended period (more than a day or two),
inform your coordinator as soon as possible.  If you do not do this,  other
systems will try to reach you while you are down, much to their annoyance.
Never put an answering machine or similar device on your phone line while you
are down. If you do, calling systems will get the machine repeatedly, racking
up large phone bills, which is very annoying.

If you will be leaving your system unattended for an extended period of time
(such as while you are on vacation), you should notify your coordinator.
Systems have a tendency to "crash" now and then, so you will probably want
your coordinator to know that it is a temporary condition if it happens while
you are away.


2.4  How to Form a Network

If there are several nodes in your area, but no network, a new network can be
formed.  This has advantages to both you and to the rest of FidoNet.  You
receive better availability of nodelist difference files and FidoNews, and
everyone else can take advantage of host-routing netmail to the new network.

The first step is to contact the other sysops in your area.  You must decide
which nodes will comprise the network, and which of those nodes you would
like to be the Network Coordinator.  Then consult your Regional Coordinator.
You must send the following information:

   1) The region number(s), or network number(s) if a network is splitting
   up, that are affected by the formation of your network.  The Regional
   Coordinator will inform the Zone Coordinator and the coordinators of any
   affected networks that a new network is in formation.

   2) A copy of the proposed network's nodelist segment.  This file should
   be attached to the message of application for a network number, and
   should use the nodelist format described in the current version of the
   appropriate FTSC publication.  Please elect a name that relates to your
   grouping, for example SoCalNet for nodes in the Southern California Area
   and MassNet West for the Western Massachusetts Area.  Remember if you
   call yourself DOGNET it doesn't identify your area.

Granting a network number is not automatic.  Even if the request is granted,
the network might not be structured exactly as you request.  Your Regional
Coordinator will review your application and inform you of the decision.

Do not send a network number request to the Zone Coordinator.  All network
number requests must be processed by the Regional Coordinator.



3  General Procedures for All Coordinators

3.1  Make Available Nodelists, Difference Files, and FidoNews

Any Coordinator is responsible for obtaining and making available, on a
weekly basis, nodelist difference files and FidoNews.


3.2  Processing Nodelist Changes and Passing Them Upstream

Each coordinator is responsible for obtaining nodelist information from the
level below, processing it, and passing the results to the level above.  The
timing of this process is determined by the requirements imposed by the level
above.


3.3  Ensure the Latest Policy is Available

A Coordinator is responsible to make the current version of this document
available to the level below, and to encourage familiarity with it.

In addition, a coordinator is required to forward any local policies he re-
ceives to the level above, and to review such policies.  Although not re-
quired, common courtesy dictates that when formulating a local policy, the
participation of the level above should be solicited.


3.4  Minimize the Number of Hats Worn

Coordinators are encouraged to limit the number of FidoNet functions they
perform.  In particular, a coordinator's system should be readily available
to the levels immediately above and below, and a coordinator should not rule
on the appeal of his own decision.

Coordinators are discouraged from acting as echomail and software-distri-
bution hubs.  If they do so, they should handle echomail (or other volume
distribution) on a system other than the administrative system.

Another reason to discourage multiple hats is the difficulty of replacing
services if someone leaves the network.  For example, if a coordinator is the
echomail hub and the software-distribution hub, those services will be
difficult to restore when he resigns.

3.5  Be a Member of the Area Administered

A coordinator must be a member of the area administered. That is, a Network
Coordinator must be a member of that network by virtue of geography.  A
Regional Coordinator must be either a member of a network in his region, or
an independent of the region.


3.6  Encourage New Sysops to Enter FidoNet

A coordinator is encouraged to operate a public bulletin board system which
is freely available for the purpose of distributing Policy, FidoNews, and
Nodelists to potential new sysops.  Dissemination of this information to
persons who are potential FidoNet sysops is important to the growth of
FidoNet, and coordinators should encourage development of new systems.


3.7  Tradition and Precedent

A coordinator is not bound by the practices of his predecessor or peers
beyond the scope of this document.

In addition, a new coordinator has the right to review any decision made by
his predecessors for compliance with Policy, and take whatever actions may be
necessary to rectify any situations not in compliance.


3.8  Technical Management

The primary responsibility of any coordinator is technical management of
network operations.  Decisions must be made on technical grounds.



4  Network Coordinator Procedures

4.1  Responsibilities

A Network Coordinator has the following responsibilities:

   1) To receive incoming mail for nodes in his network, and arrange
   delivery to its recipients.

   2) To assign node numbers to nodes in his network.

   3) To maintain the nodelist for his network, and to send a copy of it to
   his Regional Coordinator whenever it changes.

   4) To make available to his nodes new nodelist difference files, new
   issues of FidoNews, and new revisions of Network Policy Documents as
   they are received, and to periodically check to insure that his nodes
   use up to date nodelists.


4.2  Routing Inbound Mail

It is your responsibility as Network Coordinator to coordinate the receipt
and forwarding of host-routed inbound netmail for nodes in your network.  The
best way to accomplish this is left to your discretion.

If a node in your network is receiving large volumes of mail you can request
that he cease and desist routing these volumes.  If he refuses to do so, then
you can request your Regional Coordinator to assign the node a number as an
independent and drop him from your network.

Occasionally a node will make a "bombing run" (sending one message to a great
many nodes).  If a node in another network is making bombing runs on your
nodes and routing them through your inbound host, then you can complain to
the network coordinator of the offending node.  (If the node is an indepen-
dent, complain to the regional coordinator.)  Bombing runs are considered to
be annoying.

Another source of routing overload is echomail.  Echomail cannot be allowed
to degrade the ability of FidoNet to handle normal message traffic.  If a
node in your network is routing large volumes of echomail, you can ask him to
either limit the amount of echomail or to stop routing his echomail.

You are not required to forward encrypted, commercial, or illegal mail.
However, you must follow the procedures described in section 2.1.7 if you do
not forward the mail.


4.3  Assigning Node Numbers

It is your responsibility to assign node numbers to new nodes in your net-
work.  You may also change the numbers of existing nodes in your network,
though you should check with your member nodes before doing so.  You may
assign any numbers you wish, so long as each node has a unique number within
your network.

You must not assign a node number to any system until you have received a
formal request from that system by FidoNet mail.  This will ensure that the
system is minimally operational.  The strict maintenance of this policy has
been one of the great strengths of FidoNet.

It is also recommended, though not required, that you call a board which is
applying for a node number before assigning it a node number.

You may not assign a node number to a node in an area covered by an existing
network.  Further, if you have nodes in an area covered by a network in
formation, those nodes must be transferred to the new network.

You should use network mail to inform a new node of his node number, as this
helps to insure that he is capable of receiving network mail.

If a node in your network is acting in a sufficiently annoying manner, then
you can take whatever action you deem fit, according to the circumstances of
the case.


4.4  Maintaining the Nodelist


You should to implement name changes, phone number changes, and so forth in
your segment of the nodelist as soon as possible after the information is
received from the affected node.  You should also on occasion send a message
to every node in your network to ensure that they are operational.  If a node
turns out to be "off the air" with no prior warning, you can either mark the
node down or remove it from the nodelist.  (Nodes are to marked DOWN for a
maximum of two weeks, after which the line should be removed from the node-
list.)

At your discretion, you may distribute a portion of this workload to routing
hubs.  In this case, you should receive the nodelists from the Hub Coordina-
tors within your network.  You will need to maintain a set of nodelists for
each hub within your network, since you cannot count on getting an update
from each Hub Coordinator every week.  You should assemble a master nodelist
for your network every week and send it to your Regional Coordinator by the
day and time he designates.  It is suggested that you do this as late as is
practical, so as to accommodate any late changes, balanced with the risk of
missing the connection with your Regional Coordinator and thus losing a week.

4.5  Making Available Policies, Nodelists and FidoNews

As a Network Coordinator you should obtain a new issue of FidoNews and a new
nodelist difference file every week from your Regional Coordinator.  The
nodelist difference file is currently made available each Saturday, and
FidoNews is published each Monday.  You must make these files available to
all nodes in the network, and you are encouraged to make them available to
the general public for download.

You should also obtain the most recent versions of the Policy documents that
bind the members of your network, and make those available to the nodes in
your network.  Policies are released at sporadic intervals, so you should
also inform the nodes in your network when such events occur, and ensure the
nodes are generally familiar with the changes.

Policy, FidoNews, and the nodelist are the glue that holds us together.
Without them, we would cease to be a community, and become just another
random collection of bulletin boards.



5  Regional Coordinator Procedures

5.1  Responsibilities

A Regional Coordinator has the following responsibilities:

   1) To assign node numbers to independent nodes in the region.

   2) To encourage independent nodes in the region to join existing net-
   works, or to form new networks.

   3) To assign network numbers to networks in the region and define their
   boundaries.

   4) To compile a nodelist of all of the networks and independents in the
   region, and to send a copy of it to the Zone Coordinator whenever it
   changes.

   5) To ensure the smooth operation of networks within the region.

   6) To make new nodelist difference files, Policies, and issues of
   FidoNews available to the Network Coordinators in the region as soon as
   is practical.


5.2  Assigning Node Numbers

It is your responsibility to assign node numbers to independent nodes in your
region. You may also change the numbers of existing nodes in your region,
though you should check with the respective nodes before doing so.  You may
assign any numbers you wish, so long as each node has a unique number within
your region.

You should not assign a node number to any system until you have received a
formal request from that system by FidoNet mail.  This will ensure that the
system is minimally operational.  The strict maintenance of this policy has
been one of the great strengths of FidoNet.

It is also recommended, though not required, that you call a board which is
applying for a node number before assigning it a node number.

You should use network mail to inform a new node of his node number, as this
helps to insure that he is capable of receiving network mail.

If a node in your region is acting in a sufficiently annoying manner, then
you can take whatever action you deem fit, according to the circumstances of
the case.

If you receive a node number request from outside your region, you must
forward it to the most local coordinator for the requestor as you can deter-
mine.  If you receive a node number request from a new node that is in an
area covered by an existing network, then you must forward the request to the
Coordinator of that network instead of assigning a number yourself.

If a network forms in an area for which you have independent nodes, those
nodes will be transferred to the local network as soon as is practical.


5.3  Encouraging the Formation and Growth of Networks

One of your main duties as a Regional Coordinator is to promote the growth of
networks in your region.

You should avoid having independent nodes in your region which are within the
coverage area of a network.  There are, however, certain cases where a node
should not be a member of a network, such as a system with a large amount of
inbound netmail; see section 4.2.

If several independent nodes in your region are in a local area you should
encourage them to form a network, and if necessary you may require them to
form a network.  Refer to section 2.4.  Note that this is not intended to
encourage the formation of trivial networks.  Obviously, one node does not
make a network.  The exact number of nodes required for an effective network
must be judged according to the circumstances of the situation, and is left
to your discretion.


5.4  Assigning Network Numbers

It is your responsibility to assign network numbers to new networks forming
within your region.  You are assigned a pool of network numbers to use for
this purpose by your Zone Coordinator.  As a part of this function, it is the
responsibility of the Regional Coordinator to define the boundaries of the
networks in the region.


5.5  Maintaining the Nodelist

As a Regional Coordinator, you have a dual role in maintaining the nodelist
for your region.

First, you must maintain the list of independent nodes in your region.  You
should attempt to implement name changes, phone number changes, and so forth
in this nodelist as soon as possible.  You should also on occasion send a
message to every independent node in your region to ensure that they are
operational.  If a node turns out to be "off the air" with no prior warning,
you can either mark the node down or remove it from the nodelist.  (Nodes are
to marked DOWN for a maximum of two weeks, after which the line should be
removed from the nodelist.)

Second, you must receive the nodelists from the Network Coordinators within
your region.  You will need to maintain a set of nodelists for each network
within your region, since you cannot count on getting an update from each
Network Coordinator every week.  You should assemble a master nodelist for
your region every week and send it to your Zone Coordinator by the day and
time he designates.  It is suggested that you do this as late as practical,
so as to accommodate late changes, balanced with the risk of missing the
connection with your Zone Coordinator and thus losing a week.


5.6  Geographic Exemptions

There are cases where local calling geography does not follow FidoNet re-
gions.  In exceptional cases, exemptions to normal geographic guidelines are
agreed upon by the Regional Coordinators and Zone Coordinator involved.  Such
an exemption is not a right, and is not permanent.  When a network is formed
in the proper region that would provide local calling access to the exempted
node, it is no longer exempt.  An exemption may be reviewed and revoked at
any time by any of the coordinators involved.


5.7  Overseeing Network Operations

It is your responsibility as Regional Coordinator to ensure that the networks
within your region are operating in an acceptable manner.  This does not mean
that you are required to operate those networks; that is the responsibility
of the Network Coordinators.  It means that you are responsible for assuring
that the Network Coordinators within your region are acting responsibly.

If you find that a Network Coordinator within your region is not properly
performing his duties (as outlined in Section 4), then you should take
whatever action you deem necessary to correct the situation.

If a network grows so large that it cannot reasonably accommodate traffic
flow during the Zone Mail Hour, the Regional Coordinator can direct the
creation of one or more new networks from that network.  These new networks,
although they may be within a single local-calling area, must still conform
to a geographical basis for determining membership.

It is your obligation as Regional Coordinator to maintain direct and reason-
ably frequent contact with the networks in your region. The exact method of
accomplishing this is left to your discretion.


5.8  Making Available Nodelists, Policies, and FidoNews

As a Regional Coordinator, it is your responsibility to obtain the latest
nodelist difference file, network policies, and the latest issues of FidoNews
as they are published, and to make them available to the Network Coordinators
within your region.  The nodelist is posted weekly on Saturday by the Zone
Coordinator, and FidoNews is published weekly on Monday by node 1/1.  Contact
them for more details on how to obtain the latest copies each week.

It is your responsibility to make these available to all Network  Coordina-
tors in your region as soon as is practical after you receive them.  The
method of distribution is left to your discretion.  You are not required to
distribute them to any independent nodes in your region, though you may if
you wish.  You are encouraged to make all these documents available for
downloading by the general public.



6  Zone Coordinator Procedures

6.1  General

A Zone Coordinator for FidoNet has the primary task of maintaining the
nodelist for his Zone, sharing it with the other Zone Coordinators, and
ensuring the distribution of the master nodelist (or difference file) to the
Regions in his Zone.  He is also responsible for coordinating the distribu-
tion of Network Policy documents and FidoNews to the Regional Coordinators in
his zone.

The Zone Coordinator is responsible for the maintenance of the nodelist for
his administrative region.  The Administrative Region has the same number as
his zone, and consists of nodes assigned for administrative purposes not
related to the sending and receiving of normal network mail.

A Zone Coordinator is charged with the task of ensuring the smooth operation
of his Zone.  He does this by supervising the Regional Coordinators.

If a Zone Coordinator determines that a Regional Coordinator is not properly
performing his duties (as outlined in section 5), he should seek a replace-
ment for that Regional Coordinator, or take other action as he sees fit.

The Zone Coordinator defines the geographic boundaries of the regions within
his zone and sets the time for the Zone Mail Hour.

The Zone Coordinator is responsible for reviewing and approving any geograph-
ic exemptions as described elsewhere in this document.

The Zone Coordinator is responsible for insuring the smooth operation of
gates between his zone and all other zones for the transfer of interzonal
mail.

The Zone Coordinators are responsible for the selection of the International
Coordinator from among their ranks.


6.2  Selection

The Zone Coordinator is selected by an absolute majority vote of the Regional
Coordinators within his zone.


7  International Coordinator Procedures

7.1  General

The International Coordinator is the "first among equals" Zone Coordinator.

The International Coordinator has the primary task of coordinating the
creation of the master nodelist by managing the distribution between the
Zones of the Zone nodelists.  The International Coordinator is responsible
for definition of new zones and for negotiation of agreements for communica-
tion with other networks.  ("Other network" in this context means other
networks with which FidoNet communicates as peer-to-peer, not "network" in
the sense of the FidoNet organizational level.)

The International Coordinator is also responsible for coordinating the
distribution of Network Policies and FidoNews to the Zone Coordinators.

The International Coordinator is responsible for coordinating the activities
of the Zone Coordinator Council.  The International Coordinator acts as the
spokesman for the Zone Coordinator Council.

In cases not specifically covered by this document, the International Coordi-
nator may issue specific interpretations or extensions to this policy.  The
Zone Coordinator Council may reverse such rulings by a majority vote.

7.2  Selection

The International Coordinator is selected (or removed) by an absolute majori-
ty vote of the Zone Coordinators.


8  Referenda

The procedures described in this section are used to ratify a new version of
FidoNet policy, which is the mechanism by which policy is changed.  This
procedure is also used to impeach a Zone Coordinator.


8.1  Initiation

A referendum on policy modification is invoked when a majority  of the
FidoNet Regional Coordinators inform the International Coordinator that they
wish to consider a proposed new version of Policy.


8.2  Announcement and Results Notification

Proposed changes to Policy are distributed using the same structure which is
used to distribute nodelist difference files and FidoNews.  Results and
announcements related to the referendum are distributed by the coordinator
structure as a part of the weekly nodelist difference file.  The Interna-
tional Coordinator provides copies to the editor of FidoNews for inclusion
there, although the official announcement and voting dates are tied to
nodelist distributions.

If it is adopted, the International Coordinator sets the effective date for a
new policy through announcement in the weekly nodelist difference file.  The
effective date will be not more than one month after the close of balloting.


8.3  Eligibility to Vote

Each member of the FidoNet coordinator structure at and above Network Coordi-
nator is entitled to one vote.  (Hub coordinators do not vote.)  In the case
of the position changing hands during the balloting process, either the
incumbent or the new coordinator may vote, but not both.

Network coordinators are expected to assess the opinions of the members of
their network, and to vote accordingly.  A formal election is not necessary,
but the network coordinator must inform the net of the issues and solicit
input.  The network coordinator functions as the representative of the rank
and file members of FidoNet.


8.4  Voting Mechanism

The actual voting mechanism, including whether the ballot is secret and how
the ballots are to be collected, verified, and counted, is left to the
discretion of the International Coordinator.  Ideally, ballot collection
should be by some secure message system, conducted over FidoNet itself.

In order to provide a discussion period, the announcement of any ballot must
be made at least two weeks before the date of voting commencement.  The
balloting period must be at least two weeks.


8.5  Voting is on a whole Policy Document

Given that Policy is intertwined and self referencing, a relatively simple
change may require several alterations of the document.  In order to simplify
the process, balloting is done on choices between whole documents, rather
than individual amendments.  In the simplest case, this means voting yea or
nay to a new document.  If a number of alternatives are to be considered,
they must be presented as whole documents, from which one is chosen.


8.6  Dual Majorities

A Policy amendment is considered in force if, at the end of the balloting
period, it has received a majority of the votes cast, and has received a
majority of the network-coordinator votes cast, and has received a majority
of the regional-coordinator votes cast.

In the case of multiple policy changes which are considered on the same
ballot, a version must receive more than 50% of the votes cast to be consid-
ered ratified.  "Abstain" is a valid vote in this case, effectively being a
vote for not changing the current policy as it simply increases the number of
votes required to ratify the proposed change.


8.7  Impeachment of a Zone Coordinator

8.7.1  Initiation

In extreme cases, a Zone Coordinator may be impeached by referendum.  Im-
peachment of a Zone Coordinator does not require a Policy violation.  An
impeachment proceeding is invoked when a majority of the Regional Coordina-
tors in a zone request the International Coordinator to institute it.

8.7.2  Procedure as in Policy Referendum

The provisions of sections 8.2 and 8.3 apply to impeachment referenda.

The dual majority described in section 8.6 applies.  Only coordinators in the
affected zone vote (even if the zone coordinator is also the International
Coordinator).

8.7.3  Voting Mechanism

The balloting procedures are set, the votes are collected, and the results
are announced by a Regional Coordinator chosen by the Zone Coordinator who is
being impeached.  The removal of the Zone Coordinator is effective two weeks
after the end of balloting if the impeachment carries.

8.7.4  Limited to once per year

The removal of a Zone Coordinator is primarily intended to be a mechanism by
which the net as a whole expresses displeasure with the way Policy is being
interpreted.  At one time or another, everyone is unhappy with the way policy
is interpreted.  In order to keep the Zone Coordinators interpreting policy
as opposed to defending themselves, at least one full calendar year must
elapse between impeachment referenda (regardless of how many people hold the
position of Zone Coordinator during that year.)

Should a Zone Coordinator resign during an impeachment process, the process
is considered null and void, and does not consume the "once per year quota".


9  Resolution of Disputes

9.1  General

The FidoNet judicial philosophy can be summed up in two rules:

    1) Thou shalt not excessively annoy others.

    2) Thou shalt not be too easily annoyed.

In other words, there are no hard and fast rules of conduct, but reasonably
polite behavior is expected.  Also, in any dispute both sides are examined,
and action could be taken against either or both parties. ("Judge not, lest
ye be judged!")

The coordinator structure has the responsibility for defining "excessively
annoying".  Like a common definition of pornography ("I can't define it, but
I know it when I see it."), a hard and fast definition of acceptable FidoNet
behavior is not possible.  The guidelines in this policy are deliberately
vague to provide the freedom that the coordinator structure requires to
respond to the needs of a growing and changing community.

The first step in any dispute between sysops is for the sysops to attempt to
communicate directly, at least by netmail, preferably by voice.  Any com-
plaint made that has skipped this most basic communication step will be
rejected.

Filing a formal complaint is not an action which should be taken lightly.
Investigation and response to complaints requires time which coordinators
would prefer to spend doing more constructive activities.  Persons who
persist in filing trivial policy complaints may find themselves on the wrong
side of an annoying-behavior complaint.  Complaints must be accompanied with
verifiable evidence, generally copies of messages; a simple word-of-mouth
complaint will be dismissed out of hand.

Failure to follow the procedures herein described (in particular, by skipping
a coordinator, or involving a coordinator not in the appeal chain) is in and
of itself annoying behavior.


9.2  Problems with Another Node

If you are having problems with another node, you should first try to work it
out via netmail or voice conversation with the other sysop.

If this fails to resolve the problem, you should complain to your Network
Coordinator and his Network Coordinator.  If one or both of you is not in a
network, then complain to the appropriate Regional Coordinator.  Should this
fail to provide satisfaction, you have the right to follow the appeal process
described in section 9.5.


9.3  Problems with your Network Coordinator

If you are having problems with your Network Coordinator and feel that you
are not being treated properly, you are entitled to a review of your situa-
tion.  As with all disputes, the first step is to communicate directly to
attempt to resolve the problem.

The next step is to contact your Regional Coordinator. If he feels that your
case has merit, there are several things he may do.  For example, he may
order a change of Network Coordinators, or even the disbanding of your
network, though this is unlikely.  If you have been excommunicated by your
Network Coordinator, that judgement may be reversed, at which point you will
be reinstated into your net.

If you fail to obtain relief from your Regional Coordinator, you have the
right to follow the appeal process described in section 9.5.


9.4  Problems with Other Coordinators

Complaints concerning annoying behavior on the part of any coordinator are
treated as in section 9.2 and should be filed with the next level of coordi-
nator.  For example, if you feel that your Regional Coordinator is guilty of
annoying behavior (as opposed to a failure to fulfill his duties as a coordi-
nator) you should file your complaint with the Zone Coordinator.

Complaints concerning the performance of a coordinator in carrying out the
duties mandated by policy are accepted only from the level immediately below.
For example, complaints concerning the performance of Regional Coordinators
would be accepted from Network Coordinators and independents in that region.
Such complaints should be addressed to the Zone Coordinator after an appro-
priate attempt to work them out by direct communications.


9.5  Appeal Process

A decision made by a coordinator may be appealed to the next level.  Appeals
must be made within two weeks of the decision which is being appealed.  All
appeals must follow the chain of command; if levels are skipped the appeal
will be dismissed out of hand.

An appeal will not result in a full investigation, but will be based upon the
documentation supplied by the parties at the lower level.  For example, an
appeal of a Network Coordinator's decision will be decided by the Regional
Coordinator based upon information provided by the coordinator and the sysop
involved; the Regional Coordinator is not expected to make an independent
attempt to gather information.

The appeal structure is as follows:

   Network Coordinator decisions may be appealed to the appropriate Region-
   al Coordinator.

   Regional Coordinator decisions may be appealed to the appropriate Zone
   Coordinator.  At this point, the Zone Coordinator will make a decision
   and communicate it to the Regional Coordinators in that zone.  This
   decision may be reversed by a majority vote of the Regional Coordina-
   tors.

   Zone Coordinator decisions may be appealed to the International Coordi-
   nator.  The International Coordinator will make a decision and communi-
   cate it to the Zone Coordinator Council, which may reverse it by majori-
   ty vote.

If your problem is with a Zone Coordinator per se, that is, a Zone Coordina-
tor has committed a Policy violation against you, your complaint should be
filed with the International Coordinator, who will make a decision and submit
it to the Zone Coordinator Council for possible reversal, as described above.


9.6  Statute of Limitations

A complaint may not be filed more than 60 days after the date of discovery of
the source of the infraction, either by admission or technical evidence.
Complaints may not be filed more than 120 days after the incident unless they
involve explicitly illegal behavior.


9.7  Right to a Speedy Decision

A coordinator is required to render a final decision and notify the parties
involved within 30 days of the receipt of the complaint or appeal.


9.8  Return to Original Network

Once a policy dispute is resolved, any nodes reinstated on appeal are re-
turned to the local network or region to which they geographically or techni-
cally belong.


9.9  Echomail

Echomail is an important and powerful force in FidoNet.  For the purposes of
Policy Disputes, echomail is simply a different flavor of netmail, and is
therefore covered by Policy.  By its nature, echomail places unique technical
and social demands on the net over and above those covered by this version of
Policy.  In recognition of this, an echomail policy which extends (and does
not contradict) general Policy, maintained by the Echomail Coordinators, and
ratified by a process similar to that of this document, is recognized by the
FidoNet Coordinators as a valid structure for dispute resolution on matters
pertaining to echomail.  At some future date the echomail policy document may
be merged with this one.


9.10  Case Histories

Most of FidoNet Policy is interpretive in nature.  No one can see what is to
come in our rapidly changing environment.  Policy itself is only a part of
what is used as the ground rules for mediating disputes -- as or more impor-
tant are the precedents.

In order to accommodate this process, case histories may be added to or
removed from this document by the International Coordinator, with such a
revision subject to reversal by the Zone Coordinator Council.  Should Policy
be amended in such a way to invalidate a precedent, Policy supersedes said
precedent.  (A carefully prepared amendment would address this by removing
the precedent reference as a part of the amendment.)

Although a case may be removed, the text of a case history may not be modi-
fied by any mechanism.  Case history is written close to the time of the
decision, by those involved with it.  Amending the text of a case history is
the same as revising history, something quite inappropriate in an organiza-
tion dedicated to moving information.



10  Appendices

10.1  General

The Appendices of this document are exceptions to the normal ratification
process.  Section 10.2 can be changed by the appropriate Zone Coordinator,
and section 10.3 may be modified by the International Coordinator (see
Section 9.10).


10.2  Timing of Zone Mail Hour

Zone Mail Hour is observed each day, including weekends and holidays.  The
time is based upon Universal Coordinated Time (UTC), also known as Greenwich
Mean time (GMT).  In areas which observe Daylight Savings Time during part of
the year, the local time of zone mail hour will change because FidoNet does
not observe Daylight Savings Time. The exact timing of Zone Mail Hour is set
for each zone by the Zone Coordinator.

In FidoNet Zone 1, Zone Mail Hour is observed from 0900 to 1000 UTC.  In each
of the time zones, this is:

    Eastern Standard Time        4 AM to 5 AM
    Central Standard Time        3 AM to 4 AM
    Mountain Standard Time        2 AM to 3 AM
    Pacific Standard Time        1 AM to 2 AM
    Hawaii Standard Time        11 PM to Midnight

In FidoNet Zone 2, Zone Mail Hour is observed from 0230 to 0330 UTC.

In Fidonet Zone 3, Zone Mail Hour is observed from 1800 to 1900 UTC.  In each
of the time Zones involved this is:


  GMT +12 Zone                        6:00 AM to 7:00 AM
  (New Zealand)

  GMT +10 Zone                        4:00 AM to 5:00 AM
  (East Australia)
  (Papua New Guinea)
  (Micronesia)

  GMT +9.5 Zone                       3:30 AM to 4:30 AM
  (Central Australia)

  GMT +9 Zone                         3:00 AM to 4:00 AM
  (Japan)
  (Korea)
  (Eastern Indonesia)

  GMT +8 Zone                         2:00 AM to 3:00 AM
  (Hong Kong)
  (Taiwan)
  (Central Indonesia)
  (Philippines)

  GMT +7 Zone                         1:00 AM to 2:00 AM
  (Malaysia)
  (Singapore)
  (Thailand)
  (Western Australia)
  (Western Indonesia)


10.3  Case Histories


Case histories of past disputes are instructive to show general procedures
and methods.  Any decision may be included in this document by a majority
vote of either the Zone Coordinator Council or the Regional Coordinators.

Policy4 significantly changes the functions of the Zone and International
Coordinators.  In the following cases which were decided using Policy3,
substitute "Zone Coordinator" for all occurrences of "International Coordina-
tor(*)".


10.3.1  The Case of the Crooked Node

A sysop of a local node was using network mail to engage in unethical busi-
ness practices.  His Network Coordinator became very annoyed at this, and
dropped the local from his nodelist.

The local appealed to his Regional Coordinator for assignment as an indepen-
dent node.  The Regional Coordinator, after checking with the Network Coordi-
nator, decided that the Network Coordinator was right to be annoyed.  Inde-
pendent status was denied.

The International Coordinator(*) did not intervene.


10.3.2  The Case of the Hacker Mailer

A sysop of a local node made use of file attaches for extra users to mail
himself the USER.BBS file from several local boards.  The sysops of these
boards felt annoyed at this, and appealed to their Network Coordinator, who
agreed and dropped the offending node from the nodelist.

The Regional Coordinator was not consulted.

The International Coordinator(*) did not intervene.


10.3.3  The Case of the Bothered Barker

A local node became annoyed with his Network Coordinator for failing to
provide services.  Repeated complaints to his Network Coordinator did not
satisfy him, so he appealed to the International Coordinator(*).

The International Coordinator(*) dismissed the complaint because the Regional
Coordinator had not been consulted.

The local node submitted his complaint to his Regional Coordinator, who
investigated the case and discovered that there was some justice to the
complaint.  He advised and assisted the Network Coordinator in configuring
his system to provide an improved level of service to the local nodes.

The Regional Coordinator also decided that the local node was being too
easily annoyed, in that he was expecting services not normally required of a
Network Coordinator.  The local node was informed as to the true duties of a
Network Coordinator, and was advised to lower his expectations.


10.3.4  The Case of the Busy Beaver

A local node which was operated by a retail establishment was engaged in
making "bombing runs" to mail advertisements over FidoNet.  His Network
Coordinator felt annoyed and handling the outgoing traffic for a commercial
operation, and asked the local node to leave the network.

The local node applied to the Regional Coordinator, and was granted status as
an independent node in his region.


10.3.5  The Mark of the Devil

A local sysop whose board was used in conjunction with voodoo rites, hacking,
phreaking, and obscene material applied to a Network Coordinator for a node
number.  The Network Coordinator deemed that this board was exceptionally
annoying, and denied the request.

The Regional Coordinator was not consulted.

The International Coordinator(*), on seeing that the Regional Coordinator had
not been consulted, dismissed the case out of hand.  No further appeals were
made.


10.3.6  The Case of the Sysop Twit

A patron of various local nodes had been roundly recognized by all sysops as
a twit.  The user obtained his own system, became a sysop, and applied for a
node number.  The Network Coordinator denied the request.  No appeals were
made.


10.3.7  The Case of the Echomail Junkie

A local node became enamored with echomail and joined several conferences,
routing his outbound mail through his network.  He then started an echomail
conference of his own and began relaying echomail between several systems,
again routing it all through his network.

His Network Coordinator observed that network performance was becoming
seriously impaired.  The offending node was told to hold it down.  A compro-
mise was reached whereby much of the echomail traffic was no longer routed
through the network, and routed echomail was limited to twenty messages per
night.  No appeals were made.


10.3.8  The Case of the Bouncing Board

A local user decided to establish a node to promote a worthy charity.  The
machine being used was also used for various other activities during the day,
and the sysop was often called away.  His coworkers would often forget to
bring the board up at the end of the day while he was away, so the node was
often down for extended periods.  The Network Coordinator, finding the node
unable to receive mail, would mark it down.  The sysop would return, restart
the board, and ask to be reinstated.

The Network Coordinator eventually decided that the sysop was not able to
maintain a reliable system, and removed him from the nodelist completely.
Subsequent requests for a node number from the same sysop were turned down.
No appeals were made.


10.5  Credits, acknowledgments, etc.

Fido and FidoNet are registered trademarks of Fido Software, Inc.




                                     Index

-1/-1,  2.3
Additional mail events in local network  2.1.8
Administrative Region  6.1
Advantages to network membership  2.2
Alteration of mail  2.1.5
Answering machine  2.3
Announcement of voting results 8.2
Annoying behavior  1.3.5, 1.4.8, 2.1.1, 2.1.2, 2.1.4, 2.1.6, 2.1.7, 2.1.8,
    2.1.11, 2.3, 4.2, 4.3, 5.2, 9, 10
Appeal chain  9.5
Availability of NodeList  1.3.4
Balloting Period  8.4
Bombing run  4.2
BossNode  1.2.1
Boundaries  1.3.2
Calling areas  1.3.2, 5.6, 5.7
Case histories  9.10, 10.3
Changing node numbers  4.3, 5.2
Commercial messages  2.1.4, 4.2
Contributions to FidoNews  1.3.1
Current nodelist  2.1.11
Daylight Savings Time  2.1.14
Difference file  4.5, 5.8, 8.2
Disclosing private mail  2.1.6
Discussion period  8.2
Disputes  9
Distribution of ballots  8.2
Down  2.3, 4.4, 5.5
Downloading by users  3.6, 4.5, 5.8
Dual majority  8.6, 8.7.2
EchoMail  1.4.5, 4.2, 9.9
Effective date (policy change)  8.2
Elections  1.4.1
Eligibility to vote  8.3
Encryption  2.1.4, 4.2
Exceptions  5.6
Excessively annoying behavior  1.3.5, 1.4.8, 2.1.1, 2.1.2, 2.1.4, 2.1.6,
    2.1.7, 2.1.8, 2.1.11, 2.3, 4.2, 4.3, 5.2, 9, 10
Exclusivity of Zone Mail Hour  2.1.8
Excommunication  2.1.12, 4.3, 5.2, 9
Exemptions, node location  1.3.2, 5.6
Familiarity with policy  2.1.2, 2.2
FidoNet, definition  1.2.6
FidoNews  1.3.1
    availability  3.1, 4.5, 5.8
FTSC  2.4
Gateway  2.1.3
Geography  1.3.2, 5.6
Glue  4.5
Hats  3.4
Host-routed mail  4.2
How to obtain a node number  2.2
Hub  1.4.6  4.4
Illegal behavior  2.1.1, 9.6
Illegal mail  4.2
Impeachment  8.7
In-transit mail  2.1.6.1
Independent node  4.2, 5.2
Inter-zonal questions  1.4.2
International Coordinator  1.4.1, 1.4.9, 7
International FidoNet Association  1.2.6
Language  1.0
Levels of FidoNet  1.2, 1.4
Local calling areas  1.3.2
Local policies  1.2, 3.3
Mail  1.4.5, 4.2
Majority  8.6, 8.7.2
Member of area administrated  3.5
Modification of mail  2.1.5
National Mail Hour  see Zone Mail Hour
Network
    advantages  2.2
    boundaries  1.3.2, 5.4
    definition  1.2.3
    forming  2.4, 5.3
    hub  1.4.6, 4.4
    numbers  2.2, 5.4
Network Coordinator  1.4.5
    procedures  4
    replacement  5.7, 9.3
Network Mail Hour  see Zone Mail Hour
New sysops  2.1.2, 3.6
Node numbers  4.3, 5.2
   obtaining  2.2
Nodelist  1.3.4, 2.2, 4.4, 5.5
    availability  3.1, 4.5, 5.8
    changes  4.4, 5.2
    current  2.1.11
    definition  1.3.4
    format  10.3
    official  1.3.4
Nodes
    definition  1.2.2
    down  2.3
Observing mail events  2.1.8, 2.1.10
Obtaining a node number  2.2
Offensive messages  2.1.5
Partial nodelist  1.3.4
Pirated software  2.1.1
Point of origin  2.1.3
Points  1.2.1, 1.4.8, 2.1.3
Policy  3.1, 3.3, 4.5, 5.8
    changing  8
    familiarity with  2.1.2, 2.2
    local  1.2, 3.3
Precedent  3.7, 9.10, 10.3
Private messsages  2.1.6
Private network  1.2.1
Private nodes  2.1.9
Problem resolution  9
Public BBS  3.6
Ratification  7.1
Referendum  1.4.1, 8
Regional Coordinator  1.4.4
    procedures  5
    replacement  6.1, 9.4
Regions  1.2.4
Replacement of coordinators  1.4.9
Replacing services  3.4
Requirements to be in NodeList  1.3.4, 2.1.2, 2.2
Resignation of ZC  8.7.4
Resolution of disputes  9
Results Announcement  8.2
Review of decisions  3.7
Review of routed traffic  2.1.4
Routing  2.1.4 - 2.1.7, 4.2
Routing Hub  1.4.6, 4.4
Rules  9.1
Speedy decision  9.7
Statute of limitations  9.6
Submissions to FidoNews  1.3.1
Sysop procedures  2
System operator (sysop)  1.4.7
Three-tiered networks  1.4.6
Time limit on decision  9.7
Timing of Zone Mail Hour  2.1.13, 2.1.14, 10.2
Top-down  1.4.9
Tradition  3.7
Trivial network  5.3
Unattended systems  2.3
Updates to nodelist  3.2
User  1.4.8
User access during ZMH  2.1.8
Vacation  2.3
Vote  8
    eligibility  8.3, 8.7.2
ZMH see Zone Mail Hour
Zone Coordinator  1.4.3, 6
    election  1.4.9, 6.2
    impeachment  8.7
    procedures  6
    removal  6.2
    resignation during impeachment  8.7.4
Zone Coordinator Council  1.4.2, 7.1
Zone Mail Hour  1.3.3, 2.1.8
    timing  2.1.13, 2.1.14, 10.2
Zones
    definition  1.2.5
    new  1.4.2
    unique  1.3.2